Cloudflare Access で Private Network を構築時に考慮すべきケース
Cloudflare Zero Trust では、Cloudflare Access というサービスが ZTNA（Zero Trust Network Access） のソリューションを実現します。
本記事では、Cloudflare Access を使って、Private Network を構築する際に、設計時のポイントとして考慮すべき必要のあるケースについて下記のようにまとめてみました。
- 拠点間通信などサーバーからのプッシュ型の通信がある場合
- 自宅等のアクセス元とリモートの社内リソースのプライベートIPが重複
- アクセス先の異なる複数の社内リソース間でプライベートIPが重複
- オンプレミスとリモートの社内リソースのプライベートIPが重複
なお、Cloudflare Access の Private Network のユースケースや構築手順については、下記のブログをご参照ください。
それでは、ケースごとの内容を見ていきます。
拠点間通信などサーバーからのプッシュ型の通信がある場合
Cloudflare Access は、リバースプロキシのように動作します。
リバースプロキシは外部から内部への通信を制御するための技術になります。
外部＝クライアントからのリクエストをコネクターが受け取り、適切な内部＝社内リソースにリクエストを転送し、その応答を返すことで通信が行われます。
そのため拠点間通信で発生する双方向のサーバー間の通信や、FTPやHULFTなどのデータ転送サービスのようなプッシュ型通信をすることができません。
このような通信は Cloudflare Access ではサポートされていないので注意が必要です。
プッシュ型通信が必要な場合は、Cloudflare だと Magic-WAN で対応することができます。
自宅等のアクセス元とリモートの社内リソースのプライベートIPが重複
自宅のホームルーター内で構成されるプライベートネットワークとリモートアクセスする先の社内リソースのプライベートIPが重複してしまっている場合は正しくアクセスすることができません。
可能であれば、ホームルーターの初期のDHCP設定で採用されがちなプライベートIPアドレス帯をコーポレートの社内リソースのプライベートIPに設定しないようにします。
BuffaloやNEC、Acerのルーターでは、デフォルトの割り当てが 192.168.1.0/24 が多いと思われます。TP-Linkなどでは、192.168.0.0/24、ELECOMなどでは、192.168.2.0/24 が多いので、出来る限りコーポレートのIPアドレスが重複しないようにします。
既にコーポレートサイドでこれらのIPを利用しており、リモートアクセスの対象となってしまう場合は、ホームルーター側の設定を変えるほかありません。
一般社員の家庭のルーターの設定を変えるなど、考えただけでもぞっとしてしまうので、コーポレート側で使わないようにするのがいいですね。。
オンプレミスとクラウド等の社内リソースのプライベートIPが重複
こちらも先程のケースと同様です。
クラウド環境を設計する際にIPが重複しないよう既に考慮されているケースが多いとは思いますが、プライベートIPが重複してしまっている場合は対処のしようがないので、IP設計を見直す必要があります。
アクセス先の異なる複数の社内リソース間でプライベートIPが重複
送信元から見て、２つ以上の別々のアクセス先のプライベートIPが重複している場合においては、Tunnel Virtual Networks という方法を使って、それぞれのリソースにアクセスすることが可能となります。
公式ドキュメントではこちらに設定方法が記載されています。
やってみる
やってみます。
先程の構成図のように、「172.31.0.0/16」の重複しているネットワークセグメントを持つ異なるVPCを２つ用意して、それぞれのインスタンスにリモートからアクセスできるか確認します。
なお、２つのインスタンスは、cloudflared がインストールされている前提で開始します。
VPC-01のインスタンスで vnet を作成します。
続けて、作成した vnet とトンネルへ 172.31.0.0/16 のルーティングを設定します。
$ sudo cloudflared tunnel vnet add sakai-vnet $ sudo cloudflared tunnel route ip add --vnet sakai-vnet 172.31.0.0/16 sakai-tunnel
VPC-02のインスタンスでも同じように設定します。
$ sudo cloudflared tunnel vnet add sakai-vnet2 $ sudo cloudflared tunnel route ip add --vnet sakai-vnet2 172.31.0.0/16 sakai-tunnel2
どちらかのインスタンスでルーティングを確認します。
$ sudo cloudflared tunnel route ip show NETWORK VIRTUAL NET ID COMMENT TUNNEL ID TUNNEL NAME CREATED DELETED 172.31.0.0/16 ** ** sakai-tunnel 2023-08-29T02:57:09Z - 172.31.0.0/16 ** ** sakai-tunnel2 2023-08-29T02:48:07Z -
WARPをインストールした端末の、WARPの設定を確認すると「仮想ネットワーク」という選択肢が出てきます。
IPアドレス帯が重複していても、sakai-vnet を選択すると VPC-01 の方に、sakai-vnet2 を選択すると VPC-02 の方にアクセスすることができました。
まとめ
Cloudflare Zero Trust で Private Network を構築する際に考慮すべきケースをまとめてみました。
今回の注意点にあげているIP設計は慎重に行う必要があります。
アクセスする先のリソース同士のネットワークセグメントが重複している場合は、Virtual Network を設定することで回避できるので、そういった場合には積極的に活用できそうです。
この記事がどなたかの一助になれば幸いです。
